tasks: stop task_create from overwriting the task it collides with - #286

Problem

A task ID is <date>-<slug>, where the slug is the title lowercased, dashed and
truncated to 40 characters (handlers/tasks.py:_make_task_id). Two titles that
differ only past that cut therefore produce the same ID on the same day — and
task_create wrote it out regardless:

• file_path.write_text(...) truncated the older task's markdown to the new body,
  taking its context and every ## Updates note with it;
• upsert_task(task_id=..., title=..., status=..., content=...) then rewrote that
  same row — ON CONFLICT(id) DO UPDATE — with the new task's title, status and
  content.

Both copies of the older task were gone, the tool answered Task created: <id>, and
nothing logged a word. Hit in production: an in-progress task lost its body, its claim
note and its findings to a follow-up task whose title shared a long prefix.

The duplicate check ahead of it does not cover this. It reports semantically similar
tasks and tells the caller to retry with confirm_duplicate=true — which was the one
flag that skipped the report and went straight into the overwrite. So confirm_duplicate
meant "overwrite", not "create a second task". Two IDs were reachable this way that were
not even similar-looking: a completed task's ID (its row still holds it while its file
sits in done/, so the new task took the row and orphaned the markdown), and the base
<date>- that every punctuation-only title shares.

Fix

_claim_task_id walks base, base-2, base-3, … and takes the first ID that is free
on all three counts, then hands back the ID it actually claimed:

O_EXCL is what makes the last one atomic: the loser of a race gets FileExistsError and
moves to the next suffix. Past 99 suffixes the create is refused with is_error=True
instead of resolved. An upsert_task that fails after the file lands unlinks it again,
so a claimed ID is not burned by a half-done create — the retry keeps the ID it was
reaching for.

Nothing else in the repo reconstructs an ID from a title (_make_task_id has exactly one
caller), and IDs are opaque keys everywhere else — nothing parses the date prefix — so a
-2 suffix is inert to every consumer. The same handler backs both the MCP tool and
POST /api/tasks, so both paths get the fix.

One deliberate non-change: POST /api/tasks returns the tool result as HTTP 200 even when
is_error is set. This adds the first is_error that route can emit, but no route in the
repo maps that field to a status code, so introducing 409 here would be a REST-contract
change belonging in its own PR.

Verification

16 new tests in tests/test_task_id_collision.py, one behaviour each: 15 fail without
the fix, and the 16th is the control pinning that non-colliding titles keep their
unsuffixed IDs. Full suite 3030 passed (base 3014 + 16).

Covered: the older task's file, row and FTS content survive; the response names the
claimed ID; suffixes keep walking to -3; completed IDs stay reserved (both with and
without a row); a row whose file is gone still holds its ID; a rival file appearing
inside the check window is not overwritten; two asyncio.gathered creates land on two
tasks; exhaustion refuses and writes nothing; a failed index write gives the ID back; and
the degenerate cases — creating straight into done, a title whose own base is another
task's -2, punctuation-only titles, and ctx.db is None.

Seven mutants, each weakening one clause, are all killed — including replacing the
exclusive create with a preceding path.exists() check, which only the in-window rival
test catches.